PLANIFICATION
et présentation de l’outil de gestion
du projet Menu Maker
By Qwenta
L’outil de gestion : TRELLO
Pour ce projet, l’outil de gestion choisi est TRELLO.
Trello est un outil visuel, simple à utiliser, qui permet
à une équipe de gérer n'importe quel type de projet,
sous forme de tableau. Outil en ligne, et basé sur les
méthodes agiles, TRELLO permet à chaque membre
de l’équipe d’interagir dans le tableau.
Les tableaux TRELLO garantissent l’organisation des
tâches et font avancer le travail. On peut les
personnaliser en choisissant les éléments à afficher
et en créant différentes listes.
Les listes permettent de définir les différentes phases
d’une tâche.
Les cartes représentent les tâches, et contiennent
toutes les informations nécessaires pour faire le
travail. On peut les déplacer dans les listes, au fur et
à mesure, pour afficher leur état.
Capture d’écran du Tableau TRELLO
du projet Menu Maker by Qwenta
Le tableau Kanban créé sur TRELLO permet
d’organiser le travail de l’équipe et de travailler
avec fluidité. Il y a 4 listes :
- A faire : Toutes les cartes y sont créées.
- En cours : Le travail commence quand on fait
glisser une carte ici. Chaque membre de l’équipe
s’attribue la carte sur laquelle il travaille.
- Test : On fait glisser une carte ici lorsque la
fonctionnalité est créée. Les tests peuvent
commencer.
- Terminé : On fait glisser une carte ici lorsque le
travail est terminé et testé. Le Scrum Master
devra valider les cartes avant de les considérer
comme terminées.
Chaque carte comporte le nom de la tâche à
effectuer, la priorité, la difficulté, la durée
prévue, et les dates de début et de fin. On va y
ajouter le nom de celui qui va s’attribuer cette
tâche. Le nombre de cartes doit rester équilibré
dans chaque liste, pour éviter les engorgements.
Aperçu des cartes de la liste : A FAIRE
1234
Détail d’une carte – Ici : Accès aux menus précédents.
Chaque carte comporte des étiquettes de couleurs , personnalisables.
Ici, nous avons Front-end, Priorité 1, Catégorie « Menus », durée 2
jours, et difficulté 13 (Estimation de la complexité de la tâche).
Chaque carte comporte des prévisions de dates (Début, fin). Le
respect de ces dates est important car il influence la durée totale du
projet.
Chaque carte comporte une User Story, une description de la
fonctionnalité à créer, les spécifications techniques nécessaires, le
niveau de priorité, et la difficulté estimée de la tâche.
Chaque carte peut accueillir une image, un lien, un fichier joint.
Chaque carte peut comporter des cases à cocher personnalisables.
Cela permet de vérifier que rien n’a été oublié. Ici, dans la rubrique
« Succès », il y a 5 cases à cocher.
Chaque carte peut être personnalisée par tous les membres de l’équipe
: Elle peut être partagée, annotée, commentée, copiée, déplacée. Avec
les powers-up, on peut créer un lien vers Google Drive, OneDrive. Une
carte peut même être associée à une branche GitHub. Cela est
pratique pour accéder facilement au code correspondant.
Le plus important enfin, lorsqu’un membre de l’équipe prend en charge
une carte, il doit y faire figurer son nom. Cela permet à toute l’équipe
de savoir ce que chacun fait.
Importance des fonctionnalités : La méthode MoSCoW
La méthode MoSCoW permet de prioriser les besoins ou les exigences du Product Backlog. L'équipe doit
s'accorder sur la priorité des fonctionnalités à réaliser, en respectant des délais raisonnables. On peut
estimer la valeur d'une User Story ou d'une tâche, avec l'un des 4 niveaux de cette échelle :
WANT TO HAVE BUT
WON’T HAVE
4
COULD HAVE
3
SHOULD HAVE
2
MUST HAVE
1
Version mobile
Exigences précises en SEO
Capter le comportement des
utilisateurs
Landing page améliorée
Moyens de paiements
Tarif intégré à Menu Maker
Blog interne Menu Maker
Infos légales
Tarifs
Exportation Deliveroo
Partage Instagram
Déconnexion
Infos utilisateur
Dashboard
Branding Restaurateur
Landing non-connectée
Login
Catégories de plats
Création de plats
Style de menu
Exportation PDF
Impression de menu
Menus précédents
Dans le cadre du projet Menu maker, on peut classer
les tâches dans cet ordre.
1/ Ce qui est obligatoire
2/ Ce qui est nécessaire
3/ Ce qu’on pourrait avoir, dans l’avenir
4/ Ce qui est inutile
Estimation de la complexité des tâches : Le planning poker
Le Planning Poker est une pratique à la fois agile et ludique, qui permet d’estimer la complexité des fonctionnalités
à développer. C’est une estimation collective des efforts nécessaires pour produire tout ou partie d’une User Story.
Tous les membres de l’équipe doivent y participer. On présente une User Story ou une tâche. Chaque membre de
l’équipe présente son estimation (En même temps). Les membres aux estimations les plus extrêmes expliquent
leur choix. Lors de la discussion, on doit trouver un consensus. Puis on refait un ou plusieurs autres tours
d’estimation pour obtenir l'unanimité. A la fin l’estimation est ajoutée à la User Story. On peut toujours affiner ces
Story Points à échéance régulière avec l’équipe, en fonction de l’avancement du projet.
Plusieurs échelles sont envisageables : Ici, nous avons utilisé la suite de Fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34…).
La suite de Fibonacci permet de refléter l'incertitude croissante avec la taille des tâches. L’estimation de
complexité de la fonctionnalité est indiquée dans chaque carte.
Composition de l’équipe
Pour ce projet, il faut prévoir :
•Un Chef de projet chez Qwenta (John )
•Un Product Owner ( Soufiane ) qui représente les
utilisateurs finaux
•Un Scrum Master ( Moi ) qui aide et protège
l’équipe des perturbations extérieures
•Un UI Designer
•Un développeur Front-end
•Un développeur Full-stack
Le développeur Full-stack devra s’occuper en priorité
de la partie Back-end. Le travail Back-end terminé, il
s’occupera de la partie Front-end.
L’UI Designer devra s’occuper de créer les
maquettes inexistantes, avant que les développeurs
puissent effectuer leur travail.
Le Scrum Master devra valider chaque fonctionnalité
avant qu’elle soit considérée comme terminée.
Gestion du projet selon la méthode agile
Le projet sera géré selon les méthodes agiles,
par des Sprints hebdomadaires. Dans une
équipe Scrum, on crée des produits complexes
en les décomposant par itérations courtes, afin
de construire le produit pas à pas, en conservant
de la souplesse au fil du temps. Ces itérations
sont des Sprints. Les Sprints d’une semaine
permettent de créer de la valeur très
rapidement. Les rétrospectives de Sprint toutes
les semaines permettent de rebondir sur des
sujets “frais”. Cela permet de s’adapter
beaucoup plus rapidement, et offre encore plus
de flexibilité.
Concernant le projet Menu Maker, il faut
envisager une durée de 8 semaines. Cela
comprend la période de développement, mais
aussi une période de tests et de mise en
production. La communication devra rester
constante avec John, le chef de projet, jusqu’à la
validation finale.
La communication
La communication entre Webgencia et Qwenta : Elle devra rester régulière entre John (le chef de projet)
et Soufiane (Le Product Owner). Elle pourra se faire par mail au quotidien et en visio-conférence pour les
réunions hebdomadaires avec toute l’équipe (Durée 60 a 90 min. sur Google Meet). Soufiane devra présenter
les avancées et suggérer les améliorations possibles. John devra valider les résultats obtenus, et
éventuellement demander de nouvelles fonctionnalités. Une réunion exceptionnelle tous les 15 jours aura lieu
entre le chef de projet, le Product Owner et le Scrum Master, pour étudier l’évolution du projet
La communication interne, au sein de Webgencia
Backlog Refinement : Réunion hebdomadaire de l'équipe durant laquelle on découpe les User Stories qui vont
être traitées lors du prochain sprint. (Durée 60 min.). Il est suivi du Planning Poker, pour évaluer la complexité
des tâches (Durée 30 min.)
Sprint planning : Réunion hebdomadaire durant laquelle l'équipe détermine les objectifs du sprint qui démarre
(Durée 60 min.)
Sprint Review : A la fin du Sprint, cette réunion hebdomadaire en présentiel, permet de faire un bilan, d’en tirer
les conséquences. Le Product Owner y participe, et peut suggérer des modifications à apporter au Backlog
(Durée 60 min.)
Sprint Rétrospective : Réunion hebdomadaire de l'équipe qui permet d’évaluer le travail réalisé, de vérifier
l'avancée du projet et de chercher le moyen d’améliorer le sprint suivant (Durée 45 min.)
En plus de ces réunions hebdomadaires, il y a aussi Le daily Scrum : C’est une réunion quotidienne obligatoire,
en présentiel, des développeurs et du Scrum Master. On reste debout pendant cette réunion. (Durée 15 min.)
Trois points sont abordés : Le travail accompli la veille, les tâches qui seront traitées aujourd’hui et les
éventuels blocages. Si un développeur rencontre un point de blocage, le Scrum Master lui vient en aide après la
réunion, pour que la réunion ne s’éternise pas.
Conclusion
Pourquoi avoir choisi la méthode agile pour la gestion de ce projet ?
De nombreux chefs de projet ne jurent que par la méthode agile depuis des années. Cette approche
moderne et fluide du projet cumule les avantages. Entre réduction des coûts, implication des
collaborateurs et satisfaction client, cette méthode semble idéale.
L’idée, lorsque l’on utilise cette approche, est d’apporter souplesse et performance à la gestion de
projet. Centrée sur l’humain et la communication, elle permet aux clients de participer au
développement d’un produit tout au long de l’avancement du projet.
Les échanges constants avec le client favorisent la construction d’une relation de confiance. Ce
dernier peut émettre des observations à chaque fin de sprint ou cycle de projet. En implémentant les
indications du client à chaque itération, le projet se rapproche du résultat attendu. Cela est
grandement facilité par l’implication de l’équipe et une très grande flexibilité.
L’utilisation de cycles courts (Sprints) et d’un outil de travail collaboratif (Kanban) permettent aux
développeurs de progresser rapidement, et de visualiser leur progression au quotidien.
